This invention relates generally to user interface controls, and more particularly to hosting such controls in a window via an interface for controlling the window.
Graphical user interfaces have become standard fare on most computers sold today. For example, versions of the MICROSOFT WINDOWS operating system provide a graphical user interface in which a pointer is positionable over windows on a screen via an input device such as a mouse or a trackball. Clicking a button on the input device when the pointer is positioned over a given feature of the window, such as a control, registers with the program hosting the window, such that the program performs a given functionality associated with the control. For example, moving the pointer over a xe2x80x9csavexe2x80x9d button in a window hosted by a word processing program, and clicking a button on the input device, typically causes the word processing program to save the current file to a storage device (such as a hard disk drive).
While graphical user interfaces may offer computer users great advantages in ease of use and productivity as compared to traditional text-only user interfaces, they make program development more difficult for computer programmers. A computer programmer, for example, must not only be concerned with programming the given functionality of a computer program, but also with providing for windows, and controls within those windows, so that users can access the functionality. Typically, this means that the programmer must be well-versed in writing programs that operate within a given operating system, such as versions of MICROSOFT WINDOWS operating systems. Using the WIN32 application programming interface (API), for example, the programmer is able to have an application program host windows, and host rudimentary controls within those windows (e.g., dialog boxes, check boxes, buttons, text-entry fields, etc.).
A programmer does not have a vast number of different controls with the WIN32 API, however, to utilize when developing a computer program. The programmer is then usually left with having to create user interface controls himself or herself for inclusion into the computer program. Development of user interface controls, however, is a tedious and time-consuming endeavor. Furthermore, many programmers that may be skilled in other areas of program development (e.g., such as a database expert), may not be similarly skilled in developing user interface controls.
Various technologies have been developed in an attempt to remedy this potential problem. ActiveX controls are currently being utilized with desktop-oriented application programs in the Microsoft Windows operating system. ActiveX controls are known within the art, and are described in Adam Denning, ActiveX Controls Inside Out (ISBN 1-57231-350-1) (1997), and David Chappell, Understanding ActiveX and OLE (ISBN 1-57231-216-5) (1996), both of which are hereby incorporated by reference. For example, in the Chappell book, on page 205, it states that qualifying as an ActiveX control (OLE Controls technology was renamed ActiveX Controls) requires only support for the IUnknown interface and the ability to self-register with the system registry. Using ActiveX controls that have already been created means that computer programmers do not have to xe2x80x9creinvent the wheelxe2x80x9dxe2x80x94that is, they do not have to create controls that have already been created by others.
However, for many programmers normally accustomed to only the WIN32 API, using ACTIVEX controls in MICROSOFT WINDOWS operating system-intended programs is not straightforward. A programmer may, for example, have to write original xe2x80x9ccontainer code,xe2x80x9d so that the ACTIVEX control may be hosted within a window via the container code. Again, many programmers may not be experienced in creation of such container code. Furthermore, hosting ACTIVEX controls within application program windows may require the programmer to have experience in Component Object Model (COM) objects, which the programmer may not have. COM is known within the art, and is described in Dale Rogerson, Inside COM (ISBN 1-57231-349-8) (1997), which is hereby incorporated by reference. Thus, even if having access to a large number of ACTIVEX controls, a programmer may still not be able to easily include them in a given computer program under development.
A limited solution to this problem is provided by the Microsoft Foundation Classes (MFC). ACTIVEX controls may be accessible through MFC for programmers who use the computer language C++ to develop computer programs, a significant disadvantage is presented to those programmers who do not utilize C++ to develop programs. That is, because MFC is typically not accessible except through C++, a computer programmer without such knowledge may find himself or herself still unable to utilize existing ACTIVEX user interface controls within computer programs the Again, however, programmer may be developing.
There is a need, therefore, for permitting computer programmers to include ACTIVEX controls in their programs in an easy-to-understand and straightforward fashion. That is, there is a need for permitting computer programmers to include ACTIVEX controls in their programs without having to resort to COM, or MFC (via C++). Ideally, a programmer should be able to include ACTIVEX controls in a computer program using precepts and constructs already familiar to him or her.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. One aspect of the invention is a computerized system having an operating system and at least one program. The operating system provides for hosting controls of a predetermined type within windows of a predetermined type via an interface for controlling the windows. The programs then utilize the interface to host one or more controls within one or more windows. In the context of versions of the MICROSOFT WINDOWS operating system, this means that the program may utilize the WIN32 API (i.e., interface) to host ACTIVEX-type controls within windows hosted by the program, also via the WIN32 API.
In other words, computer programmers who are already accustomed to utilizing the WIN32 API to host windows by their computer programs are now able to have these windows host ACTIVEX controls via the same type of commands used in utilizing the WIN32 API. Such programmers do not have to learn any fundamentally new constructs or precepts to host ACTIVEX controls under the invention. They are not required to use MFC via C++, nor use COM, nor develop their own container code for the controls.